This invention relates generally to cryptography and, more particularly, to methods and arrangements that allow widely disparate portable tokens to be employed within a static machine concentric cryptographic environment.
Cryptography is commonly employed to authenticate data, encode data, or encrypt/decrypt data in a manner that allows the data to be stored and/or transmitted securely. Cryptography is becoming more and more popular as computers and networks increase in number, size and complexity.
By way of example, public/private key pairs are commonly used in personal computers (PCs) to provide asymmetric encryption of data that is exchanged between communicating parties. Asymmetric encryption uses public-key encryption algorithms. Public-key algorithms use two different keys (known as a key pair), namely, a public key and a private key. These two keys are typically derived from extremely large prime numbers making them mathematically related. However, it is practically impossible to derive one key from the other. As suggested by their names, the public key is made public, while the private key is kept private. In a typical static machine concentric PC environment, the private key may never leave the PC on which it was generated.
Information (i.e., data) that is encrypted with either one of the keys can only be decrypted with the other one of the keys. Thus, for example, data encrypted with the private key can only be decrypted with the public key, and vice versa.
Since, public-key algorithms can be somewhat slow, particularly when encrypting large amounts of data, a digital signature can be used instead to sign the data. A digital signature can be produced by passing the data through a specific one-way hashing algorithm. The hashing algorithm produces a much smaller message digest. As a result of the hashing algorithm, the message digest is a unique value that can essentially act as a xe2x80x9cfingerprintxe2x80x9d for the larger data file. Once a message digest is created, it can be encrypted, for example, using the private key and attached to the larger data file when it is sent or otherwise provided.
As an additional safety measure, a session key may also be used during a communication session. A session key is essentially a temporary private key or secret that is shared between the communicating parties. Upon decrypting the session key the receiving party can further decrypt the encrypted data by running the hash to produce the message digest, and process it as described above.
One problem associated with such cryptography techniques is that a third party might attempt to masquerade as one of the communicating parties, for example, by fraudulently holding out a public key that is represented to be one of the communicating parties public keys. Any messages or hashes that are intended for the communicating party and encrypted with the fraudulent public key could conceivably be decrypted with the accompanying private key by the third party.
To address this problem and others, a digital certificate can be employed by the communicating parties. A digital certificate is a credential issued by a trusted organization or entity called a certification authority (CA), such as, for example, VeriSign, Inc. This credential typically contains a public key and data that identifies the certificate""s subject (i.e., the applicable communicating party). A certificate is usually issued by a CA only after the CA has verified the certificate""s subject""s identity and has confirmed that the public key included with the certificate belongs to that subject. The certificate may also include a digest of the certificate""s contents that is signed with the private key of the CA to ensure that the certificate has not been altered or forged.
A CA may also provide self-signed certificates, or root certificates, that are to be inherently trusted. A CA may itself be certified by a hierarchy of other CAs; such information is usually included within the certificate. When a digital certificate is used to sign documents and software, this information is stored with the signed item in a secure and verifiable form that can be displayed to a user to establish a trust relationship.
Over a period of time, digital certificates will tend to accumulate on a PC. These digital certificates are usually collected in a certificate store. Tools are provided, typically as application programming interface (API) functions, that allow the user to store, retrieve, delete, enumerate, verify, or otherwise maintain the digital certificates within the certificate store.
With this in mind, Microsoft Corp. of Redmond, Wash., develops software, operating systems and other applications for use with a variety of xe2x80x9cmachinesxe2x80x9d, including general and special purpose computers, PCs, portable devices, and the like. Microsoft Corp. has developed a Cryptographic API (hereinafter, generically referred to as xe2x80x9cCryptoAPIxe2x80x9d) that provides a controlled/expandable interface between applications seeking cryptographic services and programs/devices that can provide such cryptographic services. Within CryptoAPI tools (e.g., functions) are provided that can be used to manage the digital certificates in the digital store and attach the digital certificates to data files. For example, CryptoAPI maintains a certificate revocation list (CRL) that is typically issued by the CA and lists digital certificates that are no longer valid. CryptoAPI also supports a certificate trust list (CTL) that identifies items that have been signed by a trusted entity. The various digital certificates, CRLs and CTLs within the certificate store are normally kept in non-volatile memory within the machine, such as, for example, a disk file or the system registry.
The cryptographic programs/devices that can provide the requested cryptographic services may include general purpose and/or special purpose hardware/software that is added to the machine and provides the necessary unique cryptographic token. Thus, for example, CryptoAPI allows new/additional cryptography devices/tokens to be added to the machine and acts as an interface between the requesting application(s) and the added cryptographic device/tokens. This type of API functionality/interface is well known and described in greater detail in U.S. Pat. No. 5,689,565, issued Nov. 18, 1997 to Spies et al.
The above-described API functionality/interface tends to work well with static machine concentric tokens, since it basically assumes that the cryptographic device(s) is fixed in place, always available, and used only by the local machine. However, if some of the tokens are portable, then the API functionality/interface will not always be able to locate the needed token(s).
Consequently, with the recent introduction of smart cards (SCs) and other similar portable token carrying devices, there is a need for improved methods and arrangements that allow widely disparate portable tokens to be used within static machine concentric cryptographic environments. Preferably, these methods and arrangements will provide a generic interface between existing static cryptographic functions and portable cryptographic functions that reduces development efforts/expenditures and increases processing efficiency.
The present invention provides improved methods and arrangements that can be incorporated into existing static machine concentric machines and/or newly developed appliances to allow a plurality of different portable tokens to be used in support of, or as otherwise necessary for completion of cryptographic functions.
In accordance with certain aspects of the present invention, the methods and arrangements essentially provide a clean and powerful generic interface between the computing machine and the portable token device. Thus, for example, a variety of different portable token vendors may invoke or otherwise access features associated with the present invention in a manner that reduces their development efforts/expenditures while potentially increasing the processing efficiency/capability of their respective products.
Thus, for example, in accordance with certain implementations of the present invention, an arrangement is provided for use with a machine having the capability to operatively couple with at least one removable portable token device. The arrangement includes an operating system having at least one application programming interface (API) that is configured to provide an interface between application programs and a plurality of cryptographic server provider functions. The arrangement further includes at least one portable token cryptographic server provider that is operatively configured to provide an interface between the API and the portable token. At least one portable token service provider is also included in the arrangement. The portable token service provider is operatively configured to use the portable token cryptographic server provider to create an object-based information interface to the cryptographic information maintained within the portable token.
Using this arrangement, for example, portable token vendors are able to develop portable token service providers that rely on the interface and features provided by the developer of the portable token cryptographic server provider. Thus, each portable token and its associated software can interface with the computer through a generic interface.
Thus, in accordance with one exemplary interface method for each portable token, a single card control object is provided that is operatively configured to manage the portable token. From this card control object, at least one container control object is then provided and configured to manage a specific key container. Within a container control object, at least one key pair control object is provided and configured to manage at least one individual key pair maintained within the portable token.
In still another exemplary implementation, an object-based interface arrangement is provided for use within a portable token device. Here, the object-based interface arrangement includes a card control object and at least one container object enumerated under the card control object that includes evidentiary data and associated key data. The evidentiary data can include, for example, digital certificates, certificate lists, etc.
By way of still further example, a portable token apparatus is also provided for use with one or more computers, in accordance with certain aspects of the present invention. Here, the portable token apparatus includes at least one controller, an interface coupled to the controller, and memory coupled to the controller. The memory includes instructions that cause the controller to present the computer with a control object and at least one subordinate container object, when the portable token apparatus is operatively coupled to the computer. Here, the container object includes at least one digital certificate and associated key data.